home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 2752 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.4 KB
  1. Path: hubcap.clemson.edu!hubcap!mjs
  2. From: mjs@hubcap.clemson.edu (M. J. Saltzman)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Floating point calculation order
  5. Date: 23 Jan 96 20:02:13 GMT
  6. Organization: Clemson University
  7. Message-ID: <mjs.822427333@hubcap>
  8. References: <m0tedv8-0002eqC@sice.nsk.su> <3104c6d9.134061184@nntp.ix.netcom.com> <DLnE5K.2xH@microunity.com>
  9. NNTP-Posting-Host: hubcap.clemson.edu
  10.  
  11. toms@MicroUnity.com (Tom Sanders) writes:
  12. %In article <3104c6d9.134061184@nntp.ix.netcom.com>, miker3@ix.netcom.com (Mike Rubenstein) writes:
  13. %|> "Pavel A. Zemtsov" <PZEM@sice.nsk.su> wrote:
  14. %|> >  Having declaration
  15. %|> > 
  16. %|> >  double x, p, q, r;
  17. %|> > 
  18. %|> > my compiler (cc on SCO 3.2) calculated following expression:
  19. %|> > 
  20. %|> >  x = p * q / r;
  21. %|> > 
  22. %|> > as p * (q/r); (I mean, it divided first, than multiplied). That 
  23. %|> > resulted in precision loss.
  24. %|> > 
  25. %|> > Is this legal behavior?
  26. %|> 
  27. %|> Not in ANSI C, but it was legal in K&R. If memory serves, it was not
  28. %|> made illegal until very late in the standardizattion process so if
  29. %|> your compiler was written before the standard was finalized it may not
  30. %|> adhere to this.
  31.  
  32. %I am a firm believer in not allowing a compiler to make these decisions for
  33. %me.  It's best to specify with parens the order of evaluation and not leave
  34. %it up to the compiler defaults.  I would actually prefer a compiler that
  35. %gave a warning if I did have an equation that could be evaluated in more
  36. %than 1 order (something I have not done in over 20 years).
  37.  
  38. As I understand it, before ANSI, the compiler was free to even ignore
  39. parentheses and reorder the evaluation as long as the result was
  40. *mathematically* equivalent to the original expression.  So the only
  41. way to force an evaluation order was to use multi-line code with
  42. temporaries to hold the intermediate results.
  43.  
  44. Would somebody explain under exactly what circumstances an ANSI
  45. compiler is and is not allowed to reorder evaluation?  My recollection
  46. was that parentheses forced evaluation order, but leaving them off
  47. allowed the compiler the freedom to reorder.  That's not what 
  48. Rubenstein is claiming, though.
  49.  
  50. Thus, in
  51.  
  52.     x = p * q / r;
  53.  
  54. the compiler is legally allowed to do the division first, but in
  55.  
  56.     x = (p * q) / r;
  57.  
  58. it is not, so that Sanders's strategy is effective in this case.
  59.  
  60. I also recall that the unary + was supposed to be useful in enforcing
  61. evaluation order, but I can't recall how it fits in.
  62. -- 
  63.         Matthew Saltzman
  64.         Clemson University Math Sciences
  65.         mjs@clemson.edu
  66.